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Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 
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Abstract 


This document registers the Enumservice "voice" (which has a defined 
subtype "tel"), as per the IANA registration process defined in the 
ENUM specification RFC 3761. This service indicates that the contact 
held in the generated Uniform Resource Identifier (URI) can be used 
to initiate an interactive voice (audio) call. 
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Introduction 


ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that transforms 
E.164 numbers [2] into domain names and then uses DNS (RFC 1034 [3]) 
features such as delegation through NS records, and the use of Naming 
Authority Pointer (NAPTR) records, to look up the communication 
services available for a specific domain name. 


This document registers an Enumservice according to the guidelines 
given in RFC 3761 to be used for provisioning in the services field 
of a NAPTR [4] resource record to indicate what class of 
functionality a given endpoint offers. The registration is defined 
within the Dynamic Delegation Discovery System (DDDS, [5] [6] [4] [7] 
[8]) hierarchy, for use with the "E2U" DDDS application defined in 
RFC 3761. 


Enumservices have a type and subtype. This latter is optional, as it 
may be implicit in the service type. The type defines the kind of 
communication session that can be initiated using the contact 
indicated by the URI generated by the enclosing NAPTR. In 
telecommunications engineering terms, it reflects the "teleservice". 


The subtype defines the subsystem that is to be used to initiate the 
communication session. Note that the subtype definition is usually 
associated with the URI scheme that is to be used. 


Both the type and subtype (where present) must be supported for the 
NAPTR to be used by a potential correspondent. 


There are a number of DDDS applications in addition to ENUM (for 
example, see [7] and [8]). However, an Enumservice indication 
operates only within the context of the "E2U" (ENUM) DDDS 
Application. 


Whilst the protocol elements that make up ENUM are defined in the 
above documents and in this one, further examples of the use to which 
these may be put are given in other documents, for example, in ETSI 
TS 102 172 [11]. 


This document registers the Enumservice "voice" (which has a defined 
subtype "tel"), as per the IANA registration process defined in the 
ENUM specification RFC 3761. This service indicates that the contact 
held in the generated URI can be used to initiate an interactive 
voice (audio) call. 
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Terminology 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 

"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 

document are to be interpreted as described in BCP 14, RFC 2119 [9]. 

Voice Service Registration 

Enumservice Name: "voice" 

Enumservice Type: "voice" 

Enumservice Subtype: "tel" 

URI Scheme: ‘/tel:’ 

Functional Specification: 
The kind of communication indicated by this Enumservice is 
"Interactive Voice". From a protocol perspective, this 
communication is expected to involve bidirectional media streams 
carrying audio data. 
A client may imply that the person controlling population of a 
NAPTR holding this Enumservice indicates his capability to engage 
in an interactive voice session when contacted using the URI 
generated by this NAPTR. 

Security Considerations: 
See Section 5. 

Intended Usage: COMMON 


Authors: 


Rudolf Brandner, Lawrence Conroy, and Richard Stastny (for author 
contact detail, see Authors’ Addresses section) 


Any other information the author deems interesting: 


This Enumservice indicates that the person responsible for the 
NAPTR is accessible via the Public Switched Telephone Network 
(PSTN) or Public Land Mobile Network (PLMN) using the value of the 
generated URI. 


The kind of subsystem required to initiate a Voice Enumservice 
with this subtype is a "Dialer". This is a subsystem that either 
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provides a local connection to the PSTN or PLMN or provides an 
indirect connection to those networks. The subsystem will use the 
telephone number held in the generated URI to place a voice call. 
The voice call is placed to a network that uses E.164 numbers to 
route calls to an appropriate destination. 


Note that the PSTN/PLMN connection may be indirect. The end user 
receiving this NAPTR may have a relationship with a Communications 
Service Provider that accepts call initiation requests from that 
subsystem using an IP-based protocol such as SIP or H.323, and 
places the call to the PSTN using a remote gateway service. In 
this case, the provider either may accept requests using "tel:" 
URIs or has a defined mechanism to convert "tel:" URI values into 
a "protocol-native" form. 


The "tel:" URI value SHOULD be fully qualified (using the "global 
phone number" form of RFC 3966 [10]). A "local phone number" as 
defined in that document SHOULD NOT be used unless the controller 
of the zone in which the NAPTR appears is sure that it can be 
distinguished unambiguously by all clients that can access the 
resource record and that a call from their network access points 
can be routed to that destination. 


4. Example of voice:tel Enumservice 


The following is an example of the use of the Enumservice registered 
by this document in a NAPTR resource record. 


SORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa. 
3.8.0 NAPTR 10 100 "u" "E2U+voice:tel" 
"1^. *S!tel:+441414960000!" 


5. Security Considerations 


DNS, as used by ENUM, is a global, distributed database. Thus, any 
information stored there is visible to anyone anonymously. Whilst 
this is not qualitatively different from publication in a telephone 
directory, it does open the data subjects to having "their" 
information collected automatically without any indication that this 
has been done or by whom. 


Such data harvesting by third parties is often used to generate lists 
of targets for unrequested information; in short, they are used to 
address "spam". Anyone who uses a Web-archived mailing list is aware 
that the volume of "spam" email sent increases when he or she posts 
to the mailing list; publication of a telephone number in ENUM is no 
different, and may be used for attempts to send "junk faxes" or "Junk 
SMS", for example. 
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Many mailing list users have more than one email address and use 
"sacrificial" email accounts when posting to such lists to help 
filter out unrequested emails sent to them. This is not so easy with 
published telephone numbers; the PSTN E.164 number assignment process 
is much more involved and usually a single E.164 number (or a fixed 


range of numbers) is associated with each PSTN access. Thus, 
providing a "Sacrificial" phone number in any publication is not 
possible. 


Due to the implications of publishing data on a globally accessible 
database, as a principle the data subjects MUST give their explicit 
informed consent to data being published in ENUM. 


In addition, they should be made aware that, due to storage of such 
data during harvesting by third parties, removal of the data from 
publication will not remove any copies that have been taken; in 
effect, any publication may be permanent. 


However, regulations in many regions will require that the data 
subjects can at any time request that the data be removed from 
publication and that their consent for its publication be explicitly 
confirmed at regular intervals. 


When placing a voice call via the PSTN (or from the Public Land 
Mobile Network), the sender may be charged for this action. In both 
kinds of networks, calling some numbers is more expensive than 
sending to others; both kinds of networks have "premium rate" 
services that can be charged at a rate considerably more than a 
"normal" call. As such, it is important that end users be asked to 
confirm placing the call and that the destination number be presented 
to them. It is the originating user’s choice whether or not to place 
a call to this destination number, but the originating user SHOULD be 
shown the destination number so that he or she can make this 
decision. 


In addition to the specific security considerations given above, all 
security considerations given in RFC 3761 apply, as well as the 
DNS-specific threats covered in RFC 3833 [12]. 

6. IANA Considerations 


The IANA has registered the Enumservice "voice" with a single subtype 


"tel" according to the framework defined in RFC 3761. The current 
document defines this Enumservice and the expected behaviour of 
clients. 
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Full Copyright Statement 
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This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the procedures with respect to rights in RFC documents can be 
found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at 
letf-ipr@ietf.org. 


Acknowledgement 


Funding for the RFC Editor function is provided by the IETF 
Administrative Support Activity (IASA). 


Brandner, et al. Standards Track [Page 8] 


